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September 7, 1998 



Network Operating System 
for Telecom 

Martin Snelgrove, Michael Stumm, Mauricio De Simone 



A draft white paper overview of WSTs proposed NOS, to be used for 
Internal project definition and as an initial draft for patent applications. 



WST is developing a telecommunicatioos system with two key but distinct components: wireless connectivity and 
an oi>cn software architecture. This document focu:ses on the software, but includes brief descriptions of relevant 
hardware issues. 

The two components combine to make a system that gives service providers access to end users (the wireless link) 
and a platform (the open OS) for developing a wide range of specialized voice and data services. Physically, the 
system consists of a collection of "palchpoints** in the end-user*5 homes or businesses, connected to a network of 
basestations through a third-generation (data-capable) cell-phone link. The patchpoints support voice (through RJ- 
1 1 jacks) and data (through an Ethernet coimection). 

The system is data-centric in that it uses a very general model of telecommunications, with voice services as a par- 
ticular case, but voice is a key *^lsc case" for which good performance is a must. 

We are defining an applications programming interface (API) which will permit third-party developers to develop 
new call-processing and filtering software. The business advantages are that we punch above our weight with the 
help of third parties and that they can adapt to market niches that we wouldn't see. The key technical reqiuremeots 
are that the API be very secure and very clean, and these arc advantages for our own developers too. 

The network operating system is distributed over the entire collection of patchpoints and basestations. Key require- 
ments in designing it are scalability, performance and reliability, all obtained with modem distributed-OS software 
techtuques such as the use of narrowly-defined servers, efficient message-passing, and process migration. 

In contrast to conventional telephony systems, which involve interconnecting several types of specialized comput- 
ers with predefined functions, we have undi£ferentiated hardware resources that are assigned tasks dynamically. 
This reduces design costs for us and inventory and engineering cost for service providers. 

We define a "middleware** layer that abstracts the key elements of communications (connectivity and quality of ser- 
vice) from the detailed implementations in IP' , ATM, frame relay or circuit-switched networks. This allows our 
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developers to make applications that arc portable and future-proofed. We connect to the PSTN and other networks 
at gateways- 

Our hardware is based where possible on PC hardware, to get high- volume consumer costs. Network interfaces 
(e.g. Tl) are available off-the-shelf, but in order to get ahead of the pack on the critical wireless link (we*re using a 
standard due to be finalized in the year 2000 and not expected to ship in volume for cellular telephony until 2003) 
we're developing a custom modem board for it. This board will be designed as bare-bones but flexible hardware 
("RISC philosophy") and will implement only the physical layer, with some flexible hardware support for the link 
layer. 

The wireless link standard we are working with is the FDD version of the AREB wideband CDMA proposal. A key 
problem in CDMA is that Qualconmi charge high licence fees, and there is a business risk that the final standard 
relies on their technology. In this case we will support both proprietary and standard versions, with the proprietary 
versions winning on cost and the standard versions on compatibility. Our modem hardware will be flexible enough 
to work either way. 



1 -0 The Physical Network 



Figure 1 describes our network from a physical point of view, with basestations connected to a network "cloud**, 
illustrating several types of connectivity that we should be able to handle. A simpler picture would just connect all 
basestations together through IP, but that would cost us the ability to exploit the strengths of ATM and of point-to- 
rr point or LAN connections between our basestations. That could limit our ability to deliver high quality of service. 

Maintaining the freedom to use different types of netw<^ and the ability to track the changes in IP, will involve 
our defining a "middleware" layer that expresses networking at a more abstract level than allowed by ATM or IP. In 
particular we will have to do a careful job of defining the trade-ofk between quality of service and {Mice. These 
connectivity and quality negotiating definitions will be key parts of our API. 

The basestations are rugged commercia] PCs with specialized cards, such WST radio cards, where necessary. The 
standard platform gives us the economies of scale of the PC industry. The patchpoint will use PC-market chips, but 
will have to fit in a small footprint and will have to have a very low unit cost, so it will be a (simple) custom design. 
An option we should consider is making a PC-card (perhaps PCI) version of a patdipoinL 

The wireless link will be based on the emerging '^G" (third generation cellular radio) standard, which is specified 
to be able to provide data rates up to 2Mb/s in fixed applications such as ours, though that rate may hog an unac- 
ceptable amount of bandwidth in a typical system. Section 4.0 outlines important properties of the wireless link. 

**Power usets*', who want more bandwidth than wc can economically provide, may be wired to our system and still 
be able to use our software: the wireless and open-system aspects of WST*s product are distinct 

1.1 DSP Hardware 

We need to support signal processing at MHz rates in the radio modem and at audio rates in telephony coders and 
fax modems. A tradidonal architecture would have the MHz processing done in an ASIC, the audio-rate work done 
in a specialized DSP, and the control in a microprocessor. 



lu 



1. We'll use IP" for Imcraet Protocol and "IPR- for Tntenemial Property (Rights), to avoid ambiguity. The main form of IPR 
we're focussing on ai the moment is the patent 
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FIGURE 1 . Service provider "A* has a network of WST basestations CBS-A") that refies on IP and 

ATM routers to provide a backbone; users have patchpoints CVP") connected to 
basestations with redundant illumination where possit>te. WSi or other gateways 
connect to the pubTic switched telephone network and other proprietary networks; users 
store voice-mad on rented disks; and the network software collaborates where possible 
with WST equipment owned by other providers such as "B'. 

Wc need quite a flexible radio, because 3G standards are evolving and handle multiple rates, so soinc progiamma- 
bility is needed in the modem. It will initially be implemented on an FPGA» which is a conventional first step in 
ASIC development, but the final design will look like an FPGA specialized to signal processing. This may be capa- 
ble of handling some of the audio signal processing as well as radio-modem functions, and will be programmed in 
VHDL (probably with some constraints to make synthesis easier). There may be value in partnering with Morphlcs 
on this, if ihcy have anything real to contribute, and we should have someone FPQA-sawy on the radio team. Mak- 
ing VHDL code something that can safely be loaded firom a library and attached to a user's process is desirable, 
since it maintains the full signal-processing flexibility diat we are aiming aL 

The microprocessor will be a higji-powered consumer part, and these have special support for computer graphics 
(e.g. the MMX instruction set) that wc may be able to retarget for audio DSP. A DSP specialist will be needed to 
evaluate the capabilities of these machines for filtering and modem functions. A partnership widi Gao Research 
may help, since they are implementing standard modems in Pentium software. 

It is not clear that wc will need a conventional DSP, and avoiding using one will reduce the complexity of our soft- 
ware maintenance effort, paiticulariy as time passes and we end up with several generations of hardv^are. We 
should include one only after it is proven that wc can't use the FPGA or CPU to do a vital job. 
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2:0 Three Telecom Issues 



Broadly, telecommumcauons involves switching, billing and provisioning. Every packet through the network 
involves all three issues, and making a good system will require us to deliver on all three. Third parties will write 
call processing software that configures the system for their data, and that must always set up the system so that all 
three are handled consistently In an open network it is not necessarily in the best interests of a software developer 
that bUlmg be handled properly, and we should not expect the developer to understand provisioning issues s^ 
maintaining consistency at the same time as oflFering flexibility is a key requirement on our middleware. * - ' 

Switching involves moving data around the network and processing it as necessary on the way. A natural view of 
Ais« that call proc^sing software defines a graph whose nodes process data an^^^ 

scnber as parucularly interesting nodes. We will often leave a lot of the hard work to the bLkbone wWch wouW 
n^pical y contain Inte^et or ATM routers. We wiU need to be able to describe a wide range of perfo^ZS pari 
eters of processing nodes and of links so that calls can be set up properly. This will be th^ topic of SccSo. 

S!.H°.!!.l^'"l!-°"f ^ ^u"^*" °^ ^ * "^'"^ "^^""^ '^"""^'^ destinations of calls for postprocessing but we 
need to think this through at a deeper level so as to be able to extend readily to new paymenrS:Co5es feu^h^ 

defin jLt ■ , ' T"''"' '^"^ P^'*' '^'^ becausethe differem^e is on^^^ J 

ler'sl^n ^ T'^'^ ^''^ and billing informadon available^tte 

^soor.« / H "I; T"' "i^ '"^'^'^ sophisticated price negotiation mechanisms so that system 

resources are used efficiently even with third parties setting up calls. isysicm 

"Provisioning", or more generally Operations. Administration, Maintenance and Provisioning (OAM&Pi code 
g|ves the network operator the information needed to operate. We need to report failure anS wluStics S an 
m^Lul*:"™" ^ " ^"^^ «. .hat repair, can be scheduled and decisil n!^ 22- 

^ "'ni purchases can be made on sound technical and business bases. onnewequip- 



ftj 3^ Quality of Serv ice 

« as ' 

fn 



^Tof"^ V^^n""** '^"'^^ link and the service provider's backbone, and carrying several 

types of data at that. Requirements are different for different applications, and unless we wa^ to l^Zdri^T^ 

3^ iL^ P^*^ n> method to solve that is to offer excess 

Xor^ We^o:!,d":,Tr ^i"^'^' "^'^"^ with a system in which traffic is carxi^S^verS^party 
networks. We should not rely on the IP mfiastnictnte to solve our QoS problem. 

We will be implementing a system in which contention for resources is handled by user oroccsses hidrfin w a- 

"^^"^ ^""^ |«ditionaUy implemented centralized poUcies aimed at^SSTe^of 
and have guessed at pr^onties based on such things « source and destination addre^d ^ «Sc^^ 
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Quality of Service 

conversation over a channel with a 100ms delay. Statistical properties of voice and data are also quite different, 
with data transmission being burstier and likely to use TCP. (which penalizes the network for dropping packets 
under load by retransmitting ihem, which can cause a type of instability) Bandwidth is expensive because a given 
network only has so much of it; low latency is expensive because it restricts the use of queues in the transport net- 
work, which are needed to smooth out statistical variations in loads. 




As new types of service emerge, the balance of requirements will be different. For example, video-conferencing 
fundamentally has higher data rales than voice but the same latency requirements. At the moment it is very poorly 
handled: typical video-conferencing equipment uses heavy compression to get the bandwidth down to what can be 
handled with an ISDN line, and thereby adds so much delay that conversation is- difficult — and the picture is lousy 
to boot. If we offer the performance and price required to make high-quality videoconferencing economic, the vol- 
ume of this type of traffic may build up quickly — as fax did. There may also be a hidden market for high-quality 
audio in telephony, either in specialized areas (like radio broadcast) or as a matter of price for the general public, 
and this would also tighten specifications. These new markets could offer our customers a real edge, so we have to 
be able to offer them easily. We can*t design the system so that it only works well for the current service mix. 

The telcos have revenue models based on making money from voice, and the rapidly decreasing cost of bandwidth 
puts them in a quandary: they can't afford to drop prices near costs, and until they do the new services that might 
make money won't emerge. Half of **voice calls" are now actually faxes, which also wastes resources because die 
applicaUon doesn't fundamentally require (expensive) low latency, and so businesses are emerging which bypass 
the lelco for fax. The standard interface provided by an RJ-ll jack and a line-card is limiting their ability to engi- 
neer their system. 

Subjective quality is the real measure of interest in a telephone system, and is usually quantified with an **MOSr 
(mean opinion score) by having a collection of users rate various connections on a scale of 1-4. The service pro- 
vider is faced with costs that are functions of error rates, bandwidths and latencies and an ill-defined MOS value 
model. 



Telephony has traditionally controlled load by call admission — refusing business that exceeds the volume the sys- 
tem can handle (although the effect of refusing to cany a call is that the caller dials again, so that at peak times die 
"call attempt" load goes up). The Internet Protocol model is *1>est effort", so that when load increases speed suffers, 
(for everyone, at the moment) rather than using call admission. In IP, you don't set up a call, you just send the 
packet Internet audio is moving to a model in which the coder changes as a function of network load, using a band- 
width-efficient coder when loads are high and a better-sounding one when the capacity is there. ITiis is radically 
different fix)m the call-admission model, and probably much more acceptable to the end-user a mechanical- 
sounding call on Christmas day is better than spending an hour hitting 'Yedial". This is an area in which our cus- 
tomers can beat the telcos. 

IP has been extended to handle voice latency requirements with *nypc of service" bits which can be used to assign 
pnonues in switching, "tags" which can force precomputcd routes rather than risking delays for routing computa- 
dons, and a reservation protocol (RSVP). These features arc not supported by most of the current infrastructure, 
and even with them a fab amount of network engineering is required to provide a given latency. In the Internet ' 
world, dicre is a tradc-ofif between network engineering and raw bandwidth, in that a network witii enou<»h excess 
capacity will be fast Microsoft is apparently pushing RSVP hard, because Wndows 98 uses it, so we can expect a 
lot of RSVP traffic from the Ethernet port. Unless they add billing support, though, their demands for priority won't 
be respected by cairiars. We can add the missing piece. 

/OM (Asynchronous Transfer Mode) nctworics arc an attempted compromise between the needs for data and voice 
They use a call admission model, and you have to set up a route before sending data, but they can handle bursty 
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Oitf system has to support IP and voice applications and on IP ATM ■ 

raodel ourselves on just one protocol it should nroh^M .!. ' networics. If we have to 

.nten,ose a layer Of tniddlewL thafi™^^^^^^^ 

maps easily onto the existing traffic and netwoSsfthiTwiU a^o ^ f *^ P™'"-'^ "mftat 

uo„3. and to n,a.e bilUng and operaaons respond;o^c^LS^^^^^^^ 
Leaky buckets are used both in ATM and R ^ vp » 

3.1 QoSinATM 



fn 
£3 
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ATM defines "service classes*' A through D and corresponding "QoS classes" I through 4. This is a fairly coarse set 
of categories. "Service categories" are also defined, which arc parametrized so as to allow expression of a wide 
range of needs and service guarantees. These are what wc*re most interested in: the user specifies the statistical pro- 
file of the traffic and in return the network guarantees a certain performance level. There are needs to police traffic 
(to check that it fits the promised profile) and shape it (to make sure that it does). 

Constant Bit-Rate (CBR) is straightforward in definition, setting bandwidth with a given peak cell rate (PCR). The user 
also defines the tolerable cell delay variation (CVDT). which he/she expects to smooth out with buffering at the 
destination. Cell transfer delay (CDT)» cell loss ratio (CLR) and peak-io-peak cell delay variation (CDV) are speci- 
fied by the network as its QoS guarantee. Traditional toll-quality telephony needs this service category, but it's 
wasteful. Users would expect to pay by the minute. 

Real-time Variable Bit Rate (rt-VBR) allows bursts up to a peak cell rate and maximum burst size (MBS) and guaran- 
tees cell transfer delay (CTD) and its tolerable variation (CDVT) at a specified sustainable cell rate (SCR). A leaky 
bucket can be used to police or shape traffic to this profile. This is more like what we need for modem telephony. 
Users would probably still expect to pay by the nunute. 

Non-real-time VBR doesn't guarantee CTD. It's probably more like what a Web browser would wanL Users would likely 
expect to pay by the minute, but would probably want a discount for slow packets. 

Unspecified Bit Rate (UBR) actually docs specify peak cell rate, but not a sustainable cell rate. It's basically best-effort 
Users might expect to pay by the megabyte. 

Available Bit Rate specifies a minimum cell rate (MCR) as well as the peak, and the network uses back-pressure to con- 
trol the flow: the network sends ''Resource Management" cells to the source to allow it to adapt to the capacity 
available. Users might expect to pay by the minute for the minimum cell-rate and to pay a slight piemium when 
rates are high, or (cquivalcndy from a mathematical point of view, but not psychologically) to pay for premium ser- 
vice but get a discount when forced back down to the minimum rate. This mechanism should be able to get the best 
utilization out of the network when users have sophisticated rate-adaptive coders, and might be a winner for video- 
phone. 

3.2 QoS In IPv6 and up 

• IP often uses ATM internally 

• priority and class 

• tag switching 

• Integrated Services Architecture 

RSVP (the resource reservation protocol) is a good start a packet goes from sender to receiver setting up a path, 
and another comes back reserving resources (which has to be repeated every 30 seconds). The path is supposed to 
be set up with enough priority to get tbc efifcct of a lighUy loaded network. Traffic statistics arc specified by the 
parameters of a leaky bucket, and packets beyond the stated rate arc marked as eligible for deletion. The mecha- 
nism gives us only two levels of service (high and ordinary priority). 

IP priorities are implemented differently in different subnetworks, and often not implemented at alL 

3.3 Cost and price of QoS 

• "fixed cost" at timescale of a call, hence congestion pricing 
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3.4 Warranty mechanism 

y««r mo™^ back f„ a. to 3 JtxS™? 

.cal voice burst? How long when the caUer is a ^e^.L '^^ '° * ^^"^ panuneters - how long is a tyn- 
U„8. and a bet is the natux., abstracUon oU cl^^^^''^^^:^ 'tT^'"'^ """^ ^ -<^" 2^ 
cssentuUJy bcu between the network and the subscri^J. "^"'^ m^m<^. Money-back mechanisms are 

4 0 About the Wireless Link 



quick overview of aspects of the Wireless «„k that aA^^r^S^o^^ 

s^ifr4^*ri^.e^.2ss^^^^ 

.and that radio resource allocation is alS^^S^^Zle ulf" ^y««"-»cvcl interactionf ^^n'T^ 
™«er power, bu, this increases interference ^Z f^^'^^ '"'^ ^ by i«:ieasing t^ 

Change quickly if needed. "''^ we u go for the second, but with the flexibility to 

CDMA channels are defined by a seijuence of 64. usually "chins" ffractin u- 

nclis orthogonal toeachother.andbitsa«;a„^Ltl^^^^^ 

nea oy sending the given sequence multqjlied by ±1 } CSmnels 

1. ActuaUy, complex values are used. sndARm»„„^-. 

2. Another area where we nuiy want to innovate. 
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have equal maximum bandwidth, namely the chip rate (4.096M/S, for ARIB CDMA in SMHz) divided by the code 
length (64. in this example, for a data rate of 64kh/s per channel)*. 

Channels may have different average bandwidth, though, in that system interference is set by the number of chan- 
nels actually in use, rather than the number allocated. Thus a source like voice that only transmits about 50% of the 
time uses less system capacity than a file transfer that transmits continuously. In IS-95, a system might assign only 
30 of its 64 channels, and rely on voice statistics to mean that on average only 15 of them are in use, and rarely 30 
A data user doing file transfer would use almost twice as much of the system capacity even though assigned a sin- 
gle channel. 

high FER CDMA wireless links are typically operated with frame error rates that are high (10^-3) relative to those over 
optical and wired links (<10^-9). Since this means that most errors will occur in these links, they are typically pro- 
tected with local error correction that can solve the problem immediately, rather than leaving it to an end-to-end 
mechanism like TCR For voice, forward error conrcction and power control are used to maintain an acceptable 
error rate, rather than an ARQ mechanism thai would add latency. Generally some bits need to be protected more 
carefully than others, so we would like users to be able to manipulate error control in some detaiL 

cell packing and SIR vs, local B W In principle it is possible to increase transmitter power and thereby force error rates 
arbitrarily low, but then the transmitter interferes with other users nearby; thus best cell packing density is obtained 
by deliberately operating at a marginal signal to interference ratio (SIR). CDMA standards generally have quite 
sophisticated power control to optimize overall network capacity. 

Unreliable links can be dealt with by forward error correction (error-correcting codes) or by automatic repeat 
request. ARQ wins if there is no latency constraint, as in file transfer, but for voice and video it is better to get fresh 
data than to waste time on that lost and hence moderate FEC wins. 

power control is a technical issue that is particularly important in CDMA systems. Multipath propagation of radio signals 
can cause interference between channels in CDMA, where it cannot in FDMA^. and so CDMA systems are limited 
in capacity by interference. The two ways to mitigate this are through careful power control, so that no-one trans- 
mits any more power than they have to. and advanced digital signal fffocessing techniques that cancel some of the 
interference. 

Power control is done with a combination of open-loop (if the signal you receive is strong, then the channel is good 
and you can transmit at low power) and closed-loop (the other party periodically asks you to turn your power up or 
down) techniques. The need for closed-loop control means that the radio modem itself is involved in sending and 
receiving very simple packets on a millisecond timcscale (0.625ms for ARIB) as part of every communication. 

use of random-access, paging and allocated channels. Radio channeU may be used in an Aloha style (like Ethernet, 
with packfcts an sharing a channel and occasionaUy colUding and needing to be resent) or may be aUocated to par- 
ucular users. Both styles are valuable: the Aloha (ot "random access-^ style for smafl volumes of traffic (smaU rel- 
auve to a channel) and aUocaicd channcU for larger volumes (because Ethernet only gets a utilization of 1/c in 
heavy load). In the 3G standard, as in cellular systems generally, requests for service (dialling) are carried on ran- 
dom access channels, while voice traffic is carried on dedicated data channels. 

We can (and should, acceding to 3G) transport IP cither way according to volume. Strategics for choosing between 
them can be based on traffic statistics (allocate a channel when the collision backoff gets excessive, say. or when a 

1. For further complexity, AREB divides each lOms firame into 16 timeslocs, so a data channel b reaUy 1/16 of this 

2. In FDMA systems, muldpacfa causes fading Instead. 
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queue length exceeds a threshold) but may sometimes be easier to soecifv at fh^ i i . 

demands of voice and video are relative./well un<iers.ood^„Ty 3et T^TJ^::^ZJT''^"''^ 

ticas. at the logical level. becLe only one recei^'nTer^. h^J^e paSTLt^^^^^^^ "^^ " 

clearer use of multicast is that the basestation broadcasts the Lt^rf«^LM' , k ^ 
to spealc up a little, ifs „oi,y up her."); anotherrJaT^ot ^^^^^^ 
rcdandanc communication wiU, two basestations at once, so that ei Jc^tXpId wUhou^^^^^^^ 

just overlays a vinual ^.T^Zo^^'Z^'^Z: r^'' ^'"^"^ ^^^--'^ 

STot c:~e:rtl^^^^^^^ '-^^ "-^'^ 

proper source of feedback. Paeino^ndTtir^™^.,^ k ^^^^^ to be idenUfied as the 

full power. T,c need to do ^'I^SuT^^^b^dS ^^^i^^^ *^-f"- « 

an ARQ technique (e.g. TCP) is used. ^"""S available from mutocasL A similar problem arises if 

ingbandwidthsaWnTsigniB^^rw^"-^^^^ 
- *»'--^--»'^«Plecodes:BW,uantizetionandn.«,Hc,st(7)vs^ 

ft intol.tirnes,otsthatca„beusedeffici:S;S?^^^^^^^ 

R Ikb/s can be accommodated in slots of a channel At i^^ u J^'^V^ " ^^^^ » 

g higher ..tes multiple CDMA dJlu^^t^ '"'''""^ « and at 

ity trade-off. *^ '"^^ 'o »> and it's a hardware/software/capac- 
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simpler for the shorter code, and while the transmitter must operate at a higher power (proportional to bicrate) it 
doesn't have an increased dynamic range (peak/average) requirement over the single channel. The problem is that 
bandwidth can only be allocated in power-of-two multiples of the basic rate, and a 384kfa/s connection (for exam- 
ple) would take up 16 slots. Another problem is fragmentation: as codes are allocated and given back, the available 
codes will be scattered at random, rather than bunched together (all of the leaves below a particular node of the 
binary tree) where they can be replaced by a short code. 

WST is probably better off with the shonened codes: data services are so bursty that fine control of their band- 
widths is likely meaningless, and unused capacity is not entirely wasted (as exploitation of the 50% activity factor 
for voice demonstrates) if the transmitter is shut off when not needed because system interference is reduced. The 
main penally will be that we have to move channels frequently between codes to reduce fragmentation. 

double illumination and handoff: relation to mobility, reliability and load-sharing 

A patchpoint may often be "illuminated** by signals from two or more basestations. and this fact can be exploited in 
several ways. In mobile systems it has traditionally (IS-95) been used for "soft handofT*. so that a mobile that is 
moving between two coverage areas can temporarily send its data to, and receive it from, both basestations. Then 
when it moves entirely out of range of one, the call can continue. Since the two paths can use different codes, this 
roughly doubles the workload of the modem. 

P 

During the period of double illumination, redundant packets arc discarded, and when one is received in a corrupted 
^ Slate, the other is available. This obviously makes for a reliability enhancement, though at some cost in radio 

resource capacity, and WST may wish to allow fixed users to ran in this mode when they are willing to pay for the 
b quality. 

Double illumination can also be exploited to allow load sharing between base stations (and is, in IS-95); when one 
is heavily loaded, traffic can smoothly move over to its neighbours. This economy of scope improves capacity. 



'^^ licensed and unlicensed spectrum Our system can be operated in a variety of bands with fairiy minor changes to the 
^f. radio. The choice won't make any obvious difference to the software, except for interoperability (see below), but 

• ^ might affect performance statistics. 

in 

The two key bands for us at the moment are the l.9GHz band, which is licensed, and the 2.45GHz band, which is 
£^ unlicensed. The licensed band is expensive (the service provider may have to pay $ IM and up for the license) but 

guaranteed free of outsiders adding interference. 

At 2.45GHz there arc spreading rules, (10: 1 spreading, which would limit any end-user to an acceptable 
chiprate/lO) and power limits (l(X)mW, but a function of jurisdiction) that would restrict cell size or maximion 
bitrate (a few hundred metres at 32kh/s?>. The 2.45GHz band also has a variety of interfercrs (principally micro- 
wave ovens and some wireless LANs, at die moment) and litdc control on who will enter in future, so a provider 
may run into trouble. This band is jrobably most interesting for campus-scale networks — perhaps a wireless PBX 
business. 

opportunities for IPR vs. regulatory and InteroperabtUty, both at the physical and logical layers (ARIB) 

Doing our own modem has two advantages: it guarantees that we'll have one when we need it. at a price we can 
predict, and it gives us a platform on which we can in principle innovate by modifying die ARIB standard. 

One example of an innovation is to generalize the QPSKABPSK moduiadon that die standard appUes to the sprcad- 
mg code (QPSK at 2h/symbol on die downUnk, BPSK at lb/symbol on die uplink) to QAM. This is generally not 
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desirable m mobile systems, because QAM signals get high bit-rate (6b/symbol for 64QAM. for example) at the 
cost of higher transmitter power, which in turn increases the radius over which other users are imeS witL^or 
users close to the basestauon, though, this is not an issue, and in a WLL system basestations can be pl^clos^ 



At the next level of abstracaon. the ARIB standard allocates logical channels to radio channels in panicular wavs 
and .„ panicular dedicates half the downUnk capacity to control - which seems high and which tC away il 
opportunity to take some advantage of the asymmetrical up/down loads typical of Web browsing We could 
add more use of mulncast and the option of allocating more Aloha-type capacity. 

To innovate on the radio, we need to know how tightly regulation will constrain us and decide how much t,erfor 
mance we're wUling to sacnfice for interoperability with other people's equipment. Hie only interoSilkv we 
c^ about IS at wiU. other tenninal equipment, e.g. mobiles, since we don't plan to hook o JbSa"^^ up 
other people s mobile switching centres. At the network end. we deal with oLr standards through gateway s. 
interoperability with IS-95 

a standard used for PCS ceU-'phones. and has the same ~ner=.l„«i, • . 
p structure as the wideband CDMA we are working with. It is pos^ble to h^dle^ft s^e^T^rS^^ 

^^ff--^ ^lots and can even be done (with heavier sign^'^rssTng^d T^^ly 

p some reduced system capacity) in Ae same slot Supporting PCS would be a selling point ^ ^ 



Qualconmi is pushing a W-CDMA standard diat is closer to IS-95 which is their, in » v 
chiprates in IS-95 are multiples of 9600b.s. while ii. AiUB cil^tt^trkWr<Sc^r a^^^^^^ 
^ lower chip rateoverall. at 3(1.2288Mchip/s) = 3.6864Mchip/s as against 4.096Mchi^rfor ARThuS 



ru 
in 

S.0 



need for encryption 



our own control messages between h^^^t^ur.^. . u - ™k we also Have to encrypt and authenticate 
lucssagcs oeiween l>asestations and patchpoints to avoid spoo6ng attacks, 

4.1 FDD or TDD? 
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FDD • is the technique used for PCS 'phones, and there's lots of underused licensed bandwidth out there 

• PCS conipatibiHty would in principle make it possible to turn on IS-95 compatibility in software 

• peak radiated power levels are lower, (though W-CDh4A has a TDM component that throws that advantage 
away) which will reduce power amplifier costs and may have EMC and even health advantages. 

• doesn't have TDD*s guard-time constraints, so synchronization may be simpler. ^ 

TDD • doesn't need paired bands, so can use the unlicensed (ISM) bands at 9 15 and 2450MHz. The power Itmits in 
these bands would limit the use to microcells. and unlicensed bands are more vulnerable to interference, 

• allows asymmetric allocation of bandwidth in the up- and down-links, which can be nearly 2x more efficient in 
spectrum utilization for applications like Web browsing. 

• doesn't need a duplexer at the radio front end, for a savings of $2-S5. 

• allows pccr-to-pcer networking, since there is no radio distinction between a basestation and a patchpoinL This 
in turn allows even more radical system innovation, and is a reason to go TDD in the long term. 

• has up- and down-link channels that are perfectly reciprocal.(have the same transfer functions) This allows bet- 
ter power control (possibly reducing the penalty for avoiding Qualcomm IPR) and smait-antenna algorithms 
(which increase capacity) 



5.0 Call Processing as Graph Design 



Physically, the network can be seen as a graph with the edges being communications links and the nodes being dje 
computers (patchpoinls, basestations or compute servers); logically, it's natural enough to draw a similar network 
with the nodes perfonctung computing functions and the edges still represendng communication, but with comput- 
ing functions possibly time-sharing computers and with the best implementation of the communications links being 
substantially different according to where compulation happens. Call processing software "wires up** this logical 
graph, and maps it onto hardware. 

Because the nodes in the logical graph can represent complex computing functions, such as voice coders, only cer- 
tain interconnections are valid. These nodes have properties (such as latency and CPU load, for example) of interest 
when wiring them up. Because the edges cany different types of information, the nodes are best drought of as hav- 
ing typed "ports", such as (in the voice coder case) those fcM- linearly digitized signals and for CELP-coded voice. 

If edges on the logical graph represent physical communications links, they will also have properties (B W, latency, 
PER, . ..). Edges and nodes are thus very similar objects, and so one approach would be to specialize them both 
from a superclass (GraphElement?): another approach would be to regard the physical link as a type of node with 
two ports (one for each end of the link), and so give it the same collection of properties as the computing node. Id 
this case edges may have litde meaning, and wc basically conncctPorts(codcrA,out, FECin); we'll call this the 
Lego approach, where objects are connected directly at dieir ports with no explicit representation of die connecting 
edges. Choosing to maintain explicit edges at the logical level has the advantage that the logical graph may then be 
embedded directiy in the physical one — which is an easy way of expressing the constraint that data has to get from 
one place to another The "Lego" approach may be cleaner for pure computing applications. 

Because our system is open, we have to distinguish between software that represents die interests of the cad user, 
which is typically concerned primarily widi the logical structure and only indirecdy (through its effects on cost and 
performance) widi the mapping onto hardware, and software that represents die interests of the service provider. 
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which is concerned with sharing hardware resources efficiently among a larec number of xi,- - 
cat n:,aUonship. We would prefer both types of software to be'written in wIt Javt^u^So™!^^^^ ' 
nught force us to compromise on the server side. pertoimance concerns 

hierarchy or a grouping mechanisn, can be used to hide or show detail in the communication »«n(, ; u ... 

ble to co„nea(|his. PSTN(555-12,2),, for example, and implicitly create a use "n^cUon^fh h f f"^''" P^"'" 
performance; it should also be possible to send an IP oacket wifh«„, 1~a ^"^ default coders and 

..e .phone call, it should be po^ib.e to d:::"„d Tlnr^ZtZ Zp^sre mLrrtlir'^"" ^ °^ 
can add features, for example. Hgure2 shows someof thedetailof s,?„al fl^ „aT^^?c?^^ 7;'°'^,'''"""^^ 
w,a, encryption insened at asuitable spot; the kind of thing that we wShXlrtvl^ f u 'P"""^' 

should t, » hi* *oiis „SS taS. o"^" n» A p«»y 

o«"Mly <tecrib« a«> mpptogftom pteS (tefcSS SlStw """WO".. aeroby (w„ fe.,,^ «^ , 
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canceller 




FIGURE 2. 



rules of composition would specify what kinds of nctworics make sense, and could be 
1- left for the Java level to figure out 

2. ^Plied by a strong typing mechanism for ports 

3. enforced by the objects themselves 



lf^^Z^^''^°^J^^°'^ « «U.er dynamic: forward 

Of data, and when mvcrted gives back the original type. 



ciror correction can be applied to any type 
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Representing end-to-end encryption; blocks marked •cailei* and 'network" are groups. 
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Not all the information fiows in the signal path from one subscriber to another there are also flows to and from the 
service provider's billing and management software and to the subscribers* call processing software. For example, 
if the number of uncoirected errors becomes excessive, it may be appropriate for the encoder to raise an exception 
in the call processing code so that a more robust one can be chosen. This same example also shows that it can be 
necessary to modify the graph while it is running. 

Hiding the internals of the network as in Figure 3 is probably right most of the time, but not always. For example, a 
user may want to be sure that his daia is never carried on a certain type of link (one belonging to a competitor, for 
example, or one for which availability is only statistically estimated) or that it travels by two totally independent 
paths through the network (for reliability). It is possible Qikely?) that some detail will be hidden from the end user 
("client") but not from the server. 

5.1 Prior Art 

Katosizer; Mauricio thesis?. Tornado... 

5^ Examples of signal processing objects 

First let's look at some examples of signal processing objects, with an eye to understanding what requirements they 
will place on our system. 

The signal path 

linear and adapUve filters Classic Unear filtering is used to remove DC and 60i/12(yi8OHz tones from power-line inter- 
ference and to smooth signals for downsampling; in a digital systein the downsampliug and filter are usually com- 
bined in a more efficient decimation or rate-conversion block. Other applications, standard in audio but rarer in 
telephony, include tone controls and generation of reverberation. Computation loads for simple filters are very 
small, on the order of I-IO multiply-adds per sample (80kIPS), and completely predictable. If the prtxessor on 
which a filter is running crashes and a new filter is restarted, there will be an audible "click" unless state is pre- 
served, and the internal state may vary quite quickly. 

The main requirement that filtering places on the system arc: 

• that multiply-adds at the 16-24 bit level be fast 

• that overheads for simple algorithms be small. 

Ad^tivc filters tune their coefficients to the particular caU in progress: the best-known case in telephony is the echo 
caaceUer. of which variants are designed to cancel acoustic echoes (resulting firom an acoustic path from the hand- 
set's loudspeaker to its microphone) and electrical echoes resulting from system componente (specificaUy the 
"hybnd" that converts from 2-wire to 4-wire). An echo canceUer is typically a transversal filter with a few hundred 
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taps (multiply-adds), supervised by ccxie that tries to determine the appropriate order and to turn it off when it 
appears to be unwanted or diverging. Echo cancellers that attempt to deal with acoustic echo from a speakerphone 
in an office environment need thousands of taps and sophisticated update algorithms: this area is in flux. There are 
two types of state in an adaptive filter: current coefficient values and signals. Coefficients could be checkpointed 
from time to time, but it's more expensive with signals because they vary more rapidly. 

companding techniques use ^^compression" algorithms that try to adjust gains (smoothly) so as to keep a signal's level 
. - more constant and "expansion" algorithms that adjust gains to exaggerate signal-level variations. Some techniques 
used in audio are frequency-dependent, such as Dolby companding which adjusts filter cutoffe to suppress back- 
ground hiss when signal levels are low. An extreme example of expansion is "squelch" in which signals with power 
level below a certain threshold are turned off completely to minimize idUng noise. In telephony the most common 
variant is "echo suppression" (as opposed to : "cancellation") in which the signal path from the quieter user has its 
gam reduced — which reduces the loop gain for echoing and feedback oscUlation. Companders use around 5-50 
operations per sample. 

Instantaneous companders woric on a sample-by-sample basis» and the conmion A-law case is covered under "cod- 
ers" below. 

Echo suppressors cause u-ouble for modems, so there is a convendon of watching for a 2100H2 tone at the begin- 
ning of a call as an insUiiction from a modem to disable echo suppression. 

A 3-way combiner takes three input signals and produces three outputs: in principle "C" gets voice **A+B'% "B" gets 
"A+C". etc. The idea extends naturally to N-way combining. Companding (above) is used to improve subjective 
quabiy by suppressing noise from inactive channels. 

One vertical application that we've discussed would leave the source channels uncombined, so that 3-way calls can 
be taken in stereo and the various voices more easily disdnguishcd. ThU is mosUy an application at the end-user's 
rc. because that's where the stereo speakers arc. Our contribution wiU be to provide the packets in a timely fash- 
voice coders are used to reduce the bandwidth requirements for voice signals. There are many types, but broadly they can 
act on the waveform, minimizing some mathematical measure like error power, they can model the source* or they 
can model what the car will notice. Coding for compression is an active research area, and we have to assiime th^ 
a steady stream of new coders will appear. 

Telephony classic" uses waveform coding in the form of 8kHz A-law (or ji law). Sampling is done at 8kHz on a 
signal filtered to pass the range from 300Hz to 3300Hz. The passband was defined to get good subjective scores on 
speech quality and intelligibility, and the sample rate is designed with a 33% margin over the Nyqiis't minimum in 
a trade-off between network and prcfilter costs. A-law and ^i-Iaw are specialized 8-bit floating-point representa- 
tions, chosen as a way to get roughly constant signal-to-noise over a wide range of signal levels. By comparison 
CD sound IS stereo 16-bit fixed-point sampled at 44.1kHz — needing roughly 24 times ttic bandwidth, i e Tl " 

^^S^^ '^""T^^ ^ ^P*^ ^"^^ ^ fo*- ^e^y half the bandwidth 

with ADPCM which (roughly speaking) digitizes the derivative instead. 

Most digital ceU-phones use a variant of linear prediction coding, which tries to model the incoming sound in terms 
of a sound source that simulates die vocal cords pr airflow and which in turn drives a filter that models the larynx 
ms requires less bandwidth than waveform coding because die larynx moves more slowly tiian tiie waveform but 
wories badly for anythmg other dian speech or even for speech in a noisy environmenL THese ^source cod«?'a^ 
an acuve topic of research and currenUy produce tolerable speech at output rates anywhere from 4kb/s up, A typical 
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modem coder uses about SOMIPs of DSP capacity. Coders typically operate on 20msec frames of data, and hence 
add at least that much delay to the signal path. 

Source coders typically try to detect silence, and avoiding the transmission of silence typically saves about 50% of 
bandwidth on average. At the decoding side it is conventional to replace silence with "comfort noise" so that the lis- 
teners know the connection is still live. 

Source coding is hard to use for music, because it would be necessary to model a large number of different instru- 
ments alone and in combination, so eariy digital audio (c.g. CD and DAT) just used waveform coding with enough 
bandwidth and dynamic range to satisfy (more or less) the ear. Minidisc and digital compact cassettes brought in 
coding chat reduced CD bandwidth by a factor of about 10 by using psychoacou sties, (in particular masking effects, 
where loud tones mask neaity ones for normal ears, and bandwidth can be saved by not transmitting the inaudible 
components) This type of technique can also be rate-adapted (as in RealAudio) and is a good candidate for high- 
quality speech in our networks. 

Conventional filters, companders, etc. won*t work on a coded signal, so it*s standard to decompress before filtering. 
In some cases we may be able to avoid this, though: for instance N-way combining can take advantage of silence to 
do companding **for free", and only needs to decode and recede during double-talk. 

MPEG (Motion Picture Experts Group) coders do the same type of thing for video signals that perceptual coders do for 
music. Components of a video stream at high spatial frequencies are digitized at low resolution, (using 8*8 discrete 
cosine transforms to do the filtering) and "motion estimation" is used so that components of an image that can be 
derived from adjacent frames are not retransmitted. We should probably leave MPEG for the end-user's PC. 
because it is very demanding and because specialized hardware exists for it, so we are Ukely more interested in its 
traffic properties. Straight digidzed TV costs roughly 30frames/sec*200kpixels/frame*3colours*8bits/colour. for 
144Mb/s. That's beyond what 3G wireless is built to handle, but MPEG2 gives similar quality at 2Mh/s — hence 
the 3G requirement for that rate. MPEG2 is bursty, needing more capacity when the image changes suddenly. 

At the low-quality end, videoconferencing is usuaUy done at 128kb/s. At this rate the coding process adds hundreds 
of msec of delay and the picture is poor. 

• if we get a lot of demand for fuU-motion video, then SMHz slots won't cut iL 2OMH2 slots and generous use of 
antenna diversity could support 10-40 users at that rate. 

• we may want our NOS to be able to initiate processes in (colonize?) the end-user PC so that video services can 
be set up easily. 

voice-mail and its video- and text equivalents are usually thou^t of as pure data, but should be seen as objects with meth- 
ods for reading and writing, or as filters that persist after calls complete. The reason to gencraiiwr is to aUow differ- 
ent types of coders (and encryption, and fex data, etc.) to be used in a flexible manner with voice-mail. 

Reading voice-mail can be thought of as accepting a cafl— albeit a time-shifted one. Voice-mails are all pending 
requests to the caUed party's proxy, and display the graph of the call that set them up (even tiiough it has long since 
been torn down) so that die accepting party can see data type, coding and encryption needs, source of call, check 
who is paying, 'etc. 



1. Note the odd possibility of reversed charges in voice-maiL The calling party still has to pay a deposit for disk usaee etc- in 
case the caUcd party refuses to pay. This U a good tough use case for good biU^ powi ror aisK usage etc, m 
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A single-use proxy stays alive and attached to the maU. into which you may also call to retrieve mail. This permits 
group messaging or reUieval by password, situations in which the voice-mail doesn't know who to contact In this 
sense reading voice-mail can be thought of as originating a call. 

channel coding 

FEC (Forward Error Correction) uses mathematical algorithms such as XOR convolutions between the data and a given 
sequence to produce redundant bits that can be used to detect and correct errors in transmission. For our wireless 
channels this will be very unportanL ARQ (Automatic Repeat reQuest) schemes like TCP are simple and efficient 
and can be arbitrarily reliable, but add variable latency-making them impractical for voice. In telephony, frames 
which can't be corrected using FEC are discarded, and a rate of 10"^ is considered acceptable. There are trade-offs 
among redundancy, power and error rate. 

The brute-force (and not used) example of FEC is triple redundancy, in which every bit is transmitted three times, 
and the Hamming codes used in memory systems are also fairly sU^ightforward, The algorithms used in ceUular 
telephony typically have rates of 1/2 (half the bits are data) and are subtle to derive but cheap to implement in hard- 
ware. The operations involved are generally at the bit level. It is tempting to use FPGA techniques for these 
algorithms, but we will have to consider the trade-off with software complexity: open FPGA assignment would 
suggest that third parties can write VHDL. We would probably want to be **pscudo-open** on this, applying just 

£n enough of the open philosophy to make design simple and systematic for our own purposes but not necessarily 

P allowing the unwashed to program the FPGA- 

C3 the pure Internet "dumb network" philosophy would use end-to-end error correction, but that is inefficient when a 

H particular link is known to be unreliable. If the inefficiency is just that one packet in a thousand is carried a few 

no extra Tl hops, it doesn't matter much, but FEC also increases (doubles, typically) packet size. 



Interleaving involves distributing the bits that are protected by one FEC word over several packets, so that even if one 

packet is badly corrupted (a ljurst error") no single FEC word wfll suffer more errors than it can correct Inicrleav- 
P ing adds substantially to latency. The computations are cheap, but again so bit-oriented that a hardware solution is 

tempting. 



Eacryption is needed over wireless chaimels for security, and may also be desirable end-to-end. Digital cellular systems 
54 do a mediocre job of encryption over the air, and iimnediately convert to clcanext at the basestation on the assump- 

~' tion that customers trust the telco and so as to make the signab compatible with the rest of the 'phone system. 

Encryption is the subject of a lot of research and growing commercial interest, so we have to expect a steady stream 
of new software. The computational l02uls of some of the more exotic encryption system are feiriy_ heavy, though 
"triple DES" (standaid in the banking industry) is not too bad: a collection of a couple of dozen bit-shufiles and 
0( 100) 4-bit table lookups. 

Internet traffic will best be encoded in the user's PC rather than at our patchpoints, to minimize the amount of 
cleartext running around. Still, if our system is being used to implement a virtual private network the users may be 
transmitctng cleartext around their Ethernets and tising our system to bridge remote Ethernets — in which case we 
should do the encryption so that they have a **no-fuss" secure method. 

We will have to use good encrypdon, including signature techniques, on our wireless control links. 
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modems 



A user may choose lo plug a modem inlo one of our RJ- 1 1 jacks. For Internet use that would be perverse, because 
plugging into the Ethernet jack would be faster, but it may make sense for a fax machine. We could simulate a land- 
line, perhaps with ADPCM or even straight PCM, but a voice coder would destroy the data. 

The right solution is probably to detect that the source is a fax, and implement a fax modem in software at the 
patchpoint and at the gateway closest to the receiver so that our system just needs to transmit the raw fax data. This 
can be used to economize on latency as well as on bandwidth, as long as the fax at die far end can be spoofed by our 



modems. 



IP fax is seen in the industry as an easy win. because fax u^ffic rivals voice traffic on volume, so wc should do this 
fairly early. We may want a partner to contribute the fax data pump. 

voice mail 

Current telephony practise for voice-mail is to convert calls to high-rate PCM. ship them near to die intended recip- 
ient at high bandwidth and with the usual telephony low latency, then voice-code them (to save space) and stick 



We can save on network load by leaving calls coded as for the wireless link, and by accepUng long latencies (best- 
effort service, say) for coded packets. We can leave the voice encrypted. We can use disk space wherever it is avail- 
able, though it is best to move it in advance close to the most likely place &om which it will be read — because 
latency is less tolerable when listening to voice-mail. 

Integration of a user's various mailboxes (e-mail, voice-mail and fax) is a current industry u-end and a nice vertical 
application for someone to develop. It is a big project to do right, since it may involve tcxt-to-speech and vice versa. 

links between the signal and control paths 

DTMF signaUing is the famiUar "touch-tone" technique of using a pair of tones ("Dual Tone**) each at one of four fre- 
quencies CT^uIti Frequency*') to signal switches for diaUing and end-user equipment for voice-mail hell. The 
encoders can be implemented with a simple filter or a table look-up anangement. and the receivers can be imple- 
mented with a group of filters and slicers ai roughly 30-100 operations/sample. 

pulse dialling detection involves counting strings of open-circuits on the 'phone Une at about lOHz. The '^ash" or "Unk" 
buttons often used to signal the desire to set up a 3-way call basically dial "l**. 

Both of these filters provide inputs to caD processing software from the signal path. That path doesn't have tight 
latency requirements, unless you want to suppress the DTMF in the path to a called party. • - 

voice recognition can be used to replace dialling and to offer more sophisdcatcd caU control from a conventional tele- 
phone, or to do audienticarion. Computational loads can be quite large Gargcr than voice coding, for example 
which IS typicaUy a component of voice recognition) and the area is stiU subject to active research. Computetional 
loads can also vary widely as a function of the input data. 

Ideally, voice-opcrated services can be speaker-independent, but systems that can handle large vocabularies gener- 
ally have to be iramed for the speaker. Voice authentication systems obviously need training. The need for speaker- 
dependent state suggests diat these algorithms will need access to a Ubrary (which they may also want lo updaoTif 
they are capable of continual retraining). iwupuaicu 
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The heavy loads, the use of disk resources, and the fact that voice coding is typically the first step combine to sug- 
gest that a typical voice recognition application would do voice coding on the patchpoint but might do the rest of 
the crunching on a compute server at the bascstation side. The right voice coder for recognition Tsn't necessarily a 
Standard one for wireless, so we might have the interesting situation that choosing to use voice recognition some- 
where m a call graph constrains the voice coder elsewhere. Obviously the call setup agent could just ship both kinds 
of data, but that would be an expensive use of the wireless rwource. 

call progress tones like dial-tone and ring and busy signals give call-processing software a way to drive the signal path 
Modem systems also allow the use of speech clips, although this brings up some inlcresUng quesiiotis of how to 
handle multilmgual environments. Presumably a language preference is part of a user's state. 

Users who have a good display device available would rather use it than hear ringing tones. This is an interesting 
example of the need to be able to abstract part of caO processing — we^d like to be able to "plug in" arbitrary ways 
of noufymg the end user that a line is busy v^thout changing the rest of a piece of caU processing software. 

IP packets to and from the Ethernet port 
We want to be able to filter IP packets that come in from the Ethernet port, too. There's not necessarily any warning 
that IP packets are conung, since IP is connectionless, but rfiat just means that IP filtering is set up by default. 

IP classifiers assign different types of traffic different priorities. They take a single input (unclassified IP) and produce 
^ muluple output streams. We'd need to classify packets before they go over the expensive wireless link so as to 

unpleraent the user's own policies on what to pay premium rates for. A default classifier might (for example) assim 
r- a lower priority to Web traffic than to IP telephony, or give one particular Ethernet sourx:e higher priority than otT 

5:=? crs. aassifiers belong at the network input and perhaps also at both ends of the wireless Unk. 

W IP classifiers can also manage traffic in ihc other direction, regulating flows onto the Ethernet from the patchpoint 



traffic shapmg traffic policing and radio resource managemeat go together for IP packets. Traffic shying uses leakv 
Duclccts (etc.) to force trafBc statistics to match the pro61e promised in a QoS negotiation: traffic poUcine is the 
same thing when done by trusted code at die input to a network. We'd presumably have a standard "traffic coo" fil 
.^Q ter mstaUed as part of any IP path. Tus is an example of a parameterizable filter, with cell rates and bucket siL as 

ry parameters. uutRci sizes as 

f^T*" ^ 'f "^J^ ""^ channels/slots when a queue starts to build 

W ri^. !!* S'" ^"^^ " ^ *^ cnipty for a length of 

nme comparable to a chamiel setup delay, for example) we'd assign a stream to a collision-det^Tradio cte^I 
The channels are radio resources, and management poUcies ar« needed to share them efficiently amon« dau flows 
(mcludmg flows among unrelated but neailjybasestations and patchpoints) • -K""*""^- 

header compreMion is used to avoid sending 40 bytes of IP headers over the radio channel. KTP is one standard, and cir- 
^S^nTim?^'"*'^ extreme case of header compression-source and destination SSL'l*" 

S^?**!?" "^"^"^ ^ particularly sensitive to state: if the decompression filter at the other end of the Unk 
crashes and restarts with old state, traffic may be permanendy misdirected. TTiere ar,. three obvious phUosorfu^Tfo^ 
d^g this: checkpointing critical state informauon; adding a global "^se,- signal dlTJ^rStS 

2:;::r„^droie^rnr^"^'^"^^^^^^ 



20 of 33 



Network Operating System for Telecom 



Call Processing as Graph Design 



© 



fil 

o 





IP 




classifier 


Elhemei 






driver 













FIGURE 4. 



header 
com- 
pression 



UBR 
trafEc 
cop 



header 
com- 
pression 



ABR 
traffic 
cop 



Radio 

Resource 

Client 



Radio 

Resource 

Clieni 




radio 
channel 



<^ - - - 




Radio Resource Manager 



IP packets originating from the Ethernet port are classified, compressed 
shaped/policed, and then handed to radio resource management software that runs 
across the radio link. 
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Passing state between compression/decompression pairs of filters is a problem in general, not just for crash recov- 
ery, because state mfonnanon may have to be passed at a higher level of reUability than the rest of the data. This 
suggests that there should be a "side channel" set up between pairs, as shown in Figure 5 



state path 




traffic path 



FIGURES. 



There is a need for reOaWe sWe-paths for state information. 
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firewails implement security policies that control infonnation flows between the inside and outside worlds, for example 
by forbidding telnet sessions. Firewall filters in our patchpoint would make for an interesting low-cost product, per- 
haps for small businesses. 

gateways conven IP traffic to and from other forms, for example to PSTN voice u-affic. Bascstations with PSTN interface 
cards can serve as gateways, or we can use third-party gateways by adapting to their protocols. 

caching of Web pages is a useful method of controlUng bandwidth, but can be very tricky to implement because some 

Web pages arc dynamic. In the case of the IBM/Kasparov match, for example, large volumes of traffic were oener- 
ated for pages that changed on a timescalc of minutes. An ISP could implement a cache to reduce the U-affic onto 
the backbone while speeding up response for subscribers. 

A cache shares information between users, so it doesn't necessarily show up directly in a user^s call-graph It logi- 
cally fits as part of a gateway to the Internet backbone. 

There are uicky legal issues, such as whether caching violates copyright; technical issues, such as whether caching 
makes cookie-based pages malfuncdon; and business issues such as whether it makes advertising banners and 
referrals miscount Getting these things right makes caching difficult, but the performance win makes it worth- 
while. 

packet formatting e.g, for ATM and reassembly 
figuring out tags; H323 

links between signal and OAM&P 
Quality failures: queue overrun/packet drop: algorithm failure/residue; complaint 

resource faUures or shortages: mostly at the mapping stage hut also: voice-maU overrun. 

Jinks between signal and billing 
resource use: PSTN, mailbox rentals, CPU, 

900 numbers, e-payments 

5.3 The signal-processmg object 

Zrol*'r-J^^^"T-''^ n °^J*^^' i"^^^ of ^^ch can be wired together to set up communica- 

uons graphs These objects will have "ports" between which comiections are made. What are the properties of the 
objects and their ports? Potts are part of a filter object, so we'll start there. properties of the 

strongly typed ports 

Ports should be sm>ngly typed so that meaningless connections are difficult to set up: a voice coder diat expects 
integer sample^ of a voice signal wiU do nothing useful if driven by the ouQ,ut of an FEC coder, Z^^^re- 

r^d^a"^"' ' hierarchical structure; handshakmg or backpressure signals, for example, may be associated with 

Pons usuaUy have a direction to them Cuipui or output), although they may have components that go in the oonmir. 
direcuon, as for example (again) when a handshake is involveT mponenis tnat go m the opposite 
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Examples of port types can be found in the list of filters above, but let's look at them explicitly: 

• sampled representations of audio signals: e.g. linear, A-law, ADPCM, samples of pre -emphasized signals. Pons 
of these types are also parametrized by sample rate, number of bits, and the characteristics of pre-emphasis fil- 
ters. 

• coded representations of signals, e.g. codcbook-exciied LPC. These can usually be parameterized (e.g. by filter 
length and frame and sample rate) 

• alens. which signal the occurrence of an event such as a hang-up or detection of DTMF, and reset ports 

• billing ports, through which representations of money flow. 

• parameter ports aDow call-setup software to adjust such things as sample rates, or to read them. 

• stale input/output ports synchronize complementary pairs of coders and decoders. 

• IP streams, and compressed versions (e.g. RTP streams) 
ports and their types: e.g. A-law; alert; $; OAM&P: control 
managing ports on queues 

default port connections 

resource requirements 
resource requirements e,g, CPU average: CPU max?: disk: hardware (e.g. for drivers): 

setting resource requirements 

latencies 

processing latencies 
libraries 

certification and privileges 
certification and measurement philosophies 

privileged/trusted filters needed for bilUng, OAM&P, NOS exec and scheduling. Must run on trusted hardware, 

5.4 The link object 

physical or virtual ? It 'II change, 
characterized by BW ^ QoS 
setting BW 

latency, irtcluding queues 

guaranteeing vs. measuring BWand latency 

reliability 

setting reliability; recommended coders 

costing API (for service provider's pricing software) 

bilUng cmd OAM&I^ ports 
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5.5 Call processing 

5.6 Features to demonstrate 

• role of demo vertical apps 

• stereo 3- way 

• "here I am" call forwarding; uses caller ID if possible to remotely reroute forwarding — needs authentication 

• call forward that works through a switchboard by advising the caller of what's happening — or dials the exten- 
sion 

• e-cash calls 

5.7 Project management 

Bulletproof Java is a clearly definable separate project and a potential stand-alone product If we can control it through 
licensing (cheap to everyone except com|>eUtors?), then we get a little bit of revenue at the same time that we create 
a community of software developers. We can hive the development and even some of the design off to TCS. Once 
|2 it*s there, we can move call processing that we have done in ordinary Java over to it and suddenly stan to demon- 

strate survivability. 



There are some high-level design trade-o£Es to think about Ideally, a complete copy of the program state would be 
^ maintained on a backup machine at all times, but this would be extremely slow and synchronization with calls that 

\^ change state of the network would be very tricky. Is it good enough to have die state of particular (programmcr- 

in define) objects protected? 

I- 

p 6^ Call Processing: Servers, Agents and Managers 

\U ' — 

f y intro: what is call processing? Setup, monitoring, teardown 

clarity for individual 
|0 performance for system 

6.1 Proxy 

The key feature we need for call processing is that each end user is represented by a "proxy" in our ^stem, which 
deals with 

• incoming calls, deciding which ones get to ring a 'phone, which get busy signals, which go to voice-mail. etc. 

• billing, representing the end user's policies on what to pay (900 calls? disk space for voice-mail?) and how. (bill 
me or Visa?) 

• outgoing calls, using special **speed-call" directories or voice-dialling software, etc. 

Proxies can also represent groups of users ("the operator^, •*91 1 dispatch", etc.). Generally, anything that can pay 
bills can have a proxy. It is the responsibility of the proxy to decide which telephone to ring. 
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{:0 ^ manager'' will be needed for setting up complicated types of caUs. In setting up a three-way call, for exam- 

ple, the question arises of what to do when the originating party hangs up; docs the call drop? If not, either the call- 
ing party may find itself handling a number of calls of which it isn't part or it will delegate the task to a call 
manager. The call manager mechanism can also be used to simplify the task of call setup for simple calls. 

Proxy as state machine 

Proxies define a user's poUcies for making and taking calls, and complex policies wiU cntafl complex software- but 
we want poUcies to be easily defined. Hie combination of complexity and case of use implies tfiat we wQl wailt to 
impose a structure on the coding of proxies that makes for clarity and aUows some sort of intuitive interface. The 
sequence of actions involved in taking a caU can be described by a stale machine, and the state machine can be 
edited as a graph — one which is in turn responsible for setting up switching graphs. 

Figwe 6 shows the piece of a proxy that implements the standard dialling model, for example. This representation 
can be edited graphically, and different blocks substituted to allow voice dialling or different interpretations of 
ijumbcrs. (e.g. the PBX convention •'dial 9 to get out" or something where press-and-hold of a digit gives si>eed 
dialling) * i'^'^^ 



lagers 



Users outside our system will need "generic proxies" representing legitimate uses of the PSTN, for example, or to 
represent a PSTO calling pany's intentions (caller ID, for example) to a WST proxy. A WST user who "roams" into 
the PSTN will need to be able to infonn his/her proxy of how he/she can be found. 

Well-known telecom services serve as "use cases** for a call processing architecture. A telephone call may be redi- 
rected by call forwarding or (on busy or no answer) to voice mail, for example; its billing may be rcdircctc'^ by use 
of 800 or 900 numbers; and during a call a third party can be added to set up a conference call. In a cellular system 
users must be paged over a large area to find them for a call, and incoming calls may be redirected (by means of the 
"home location register" and "visitor location register" databases) to remote locations. The user's routing model for 
simple Internet packets is as simple as that for a 'phone call, but advanced IP features such as multicast, QoS con- 
trol and mobility again bring in call setup and billing concerns. 

In a telephone system, call features may conflict (busy wait and voice-mail feamres have different responses to a 
busy signal, for example). A proxy architecture takes care of this in the sense that a program has to be written to do 
one thing or another when sensing "busy". The difficulty will return if we try to implement a feature-level descrip- 
tion language for call processing. 

We're assuming that call processing software will be written m Java; key requirements for the language are: 
^ ♦ excellent security 

Q • a large community of experienced developers 

^2 • object onentation 

i** • simple net-based distribution mechanism 

Proxies must persist in die presence of patchpoint and basestation failures, so that (for example) a user's forwarding 
instructions don't get lost during a crash. 



P Directories can be implemented as distributed databases, for scalability, and custom versions can exist A directory 

%U belongs to a user or group of users, rather than to the network provider, in an open system, we want a private 

-yellow pages" to prosper, for example, and anyway we can't forbid it because it could be provided Oess efl5- 
l^f? ciently) from any IP address. 
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FIGURE 6. Section of a calf-processing state-machine responsible for initiating caJts according to a 

converttionaJ dial-tone model 

f=% call setup is: set up your half the ideal way, ask a manager to get you a connection to someone else: they respond 

with counterproposals, the manager adjusts your graph to work. You can catch changes, or just let them go 
^= through. 

!•*> you could have a state machine that goes through a sequence of offers 

monitoring is: you can catch signals if you like. 

In 



Negotiating a connection 
E911 



ru 
in 

l,Q 6^ Directory Server 

t« distributed nature; like DNS, maybe LDAP 

World Cup tickets 

6.3 Mapping Server 



6.4 RFQ Server 

IPR? telephony, we need a mechanism in which: 

1. the call manager asks fora quote on the cost of service for its traffic load at a certain QoS. The RFQ mechanism 
may be quite subde, specif>dng a pricc^rformancc trade-oflE, but must degenerate easily to standard models. 

2. the network responds with an offer of a certain capacity and QoS at a price and with a warranty. This response 
should be as informative as possible: for example, a response to an RFQ asking for an impossibly low latency 
should respond with an offer at the minimum practical latency. 

3. the call manager accepts the quote, or perhaps tries again at a lower bandwidth or QoS. 
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4. ihc network sets up channels and reserves bandwidth- 

5. the call manager alerts the various parties to start talking. They handle ringing/busy etc. themselves, but signal 
the call manager on hang-ups, DTMF tones or hookswiich flashes, etc. The call manager is also signalled by the 
network on failures to achieve contracted pcrfonnancc» and may renegotiate rates while a call is in progress. 

6. the call manager alerts the network that the call is over 

7. the network tears down the call 

IP is a special case of this, in which a low-QoS ("best effort**) low-bandwidth (compatible with Aloha channels, for 
most users) path to arbitrary IP addresses is negotiated at power-up. The call manager monitors queue lengths on 
either side of the radio link (being signalled when queues start to fill, for example) so as to adapt its (JoS requests to 
load and bandwidth availability in a price-sensitive manner. The call manager is also signalled when packets are 
dropped. 

A more advanced IP strategy typically involves different QoS as a function of parameters that can be deduced from 
the IP header, (source and destinauon addresses, ports, TOS bits, etc.) In our system this is enforced by filter pro- 
cesses in the patcbpoint and/or network that segregate the user's IP traffic into a number of logical streams, each of 
which can have its own call manager. This allows third parties to offer **Turbo Telnct*\ for example, whereas in a 
typical modem network the priority of Telnet is fixed centrally (and low). 

Call Graph as API for negotiation 



l*-^ For new services, we cannot assume that there is a single pipe at a given bandwidth and QoS involved in a call; for 

s-"^ example, a 3- way video-conference call might have one of the branches operating as voice-only at a much lower 

£0 rate than the video branches. Our API for negotiation has to capture the whole structure of the call. For this leason. 

in and to avoid adding new constructs, we will use the call-graph itself as the key specification both of desired service 

*==J and billing method. 

Q Essentially, the call-manager software hands a "schematic*' of the desired call to the RFQ server, which looks at the 

1,0 "traffic cops" and similar blocks to determine a price, then sets parameters in **teller" blocks that feed money into 
f U components. The modified graph is then returned to the call-manager for approval. 

^2 Figure 7 shows the graph that a call manager might pass for an RFQ on a simple call with a given bandwidth. The 
switching sub-structure is enclosed in a high-level block, and a particular payment method is attached to the entire 

CO block, but with the per-minute rate not yet filled in; that's the job of the RFQ server. 

For use as part of the RFQ process, the calling graph needs to be able to express anything of interest to the user or 
the network, including latency, frame error rate, and nature of warranties. These things are expressed by including 
policing blocks in the call graph that enforce or test for compliance. The policing blocks have to trusted, which is 
an additional task for our certification group. We also have to be careful that a spoofing attack doesn't undermine 
the integrity of billing. 

latency cops specify allowable latency. If we have accurate time references available, (e.g, by using GPS) then the struc- 
ture of Figure 8 could be used. A timestamp is added to outgoing packets (perhaps aU of them, in the case of IP. or 
perhaps just those starting bursts, as in telephony), and checked at the receiver. 

The latency cop can also implement the buffering needed to eliminate the variability of incoming delay, which is 
important in voice applications. In this situation, the RFQ process estimates the worst-case delays ihroiigh the 
channel, then sets a parameter in the latency cop that sets its maximum bufifer size and how full it should initially be 
before passing data on. 
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FIGURE?. 
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A simple call ready for a quote; this graph is passed to the RFQ server, which sets the 
rate (?/minute) and passes it back. 
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'RE 8, - A call with a latency specification and a warranty. 

When the latency cop detects a failure, it signals a warranty violatioa to the warranty service (Figure &). which ii 
turn reduces the time acnially charged according to an agreed poUcy. The call manager sets up its desired policy, 
and the RFQ server may choose to charge a premium in order to assume that risk. 

If absolute tune references are not available, essentially the same structure can be used to measure and enforce 
roimd-irip delays. The policing function moves into the timestamp service, and an echo mechanism replaces the 
onginal cop. The echo mechanism may be rolled in witii ARQ (c.g. for TCP) to save traffic. 
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Buffering to eliminate delay variability in each one-way path is more subtle in the case that absolute time refer- 
ences arc not available, because the average input and output rates might not match. A "frequency-locked- loop" 
type of approach in which output sample rates are adjusted so as to keep a buffer size stable is used to solve the 
problem. 

FER cops can be rolled in with error-checking at the destination, and work in much the same way as latency cops: when a 
frame error is detected, they signal a warranty failure. 

detailed billing services are just interposed between the body of the call and the ultimate source of money (e.g. VISA), as 
shown in Figure 9. The call manager passes the billing service a copy of the entire call graph on call setup (so that 
it has all the necessary information to describe the call), and it also receives copies of warranty-failure alerts. It 
stores its results on rented disk, which can then be read through a Web interface or printed and mailed. 
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A call with detailed bilfing 



multiple bUling sources, aie handled by attaching different money sources to different subgraphs, as in Figure 10. This 
will be useful in the case of point-to-multipoint services, like MBone or other pseudo-broadcasts. 

976 calls or other calls that involve one user paying another are set up similarly: the payee includes a payment cop in a 
subgraph that will insist on money flowing in at a certain rate or on ccnain signals, and offers that subgraph to 
potential clients — who pay service charges both to die system and the payee, as in Figure 1 1 . The RFQ process sets 
up these tjurd-party flows in the same way as ordinary system charges. Because the 976 operator docs not include a 
inoney source in the service subgr^h. he can't be charged. This is also an example of a case in which the 976 ser- 
vice operator would not allow cUents to descend the hierarchy and see the internal structure of the service (such as 
home 'phone numbers of the employees). 

Robbie Q2 

Telephony classic: one QoS, one price take/leave, 
broker mechanism; brokers taking a cut. 
charging for RFQs 
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FIGURE 10. 



A call with multiple independent bills, e.g. for a broadcast-type service. 




FIGURE 11. 



A 976 call. The 976 service provides a black box with voice and money ports to which 
a caller attaches money and signals. ' *^ "niwi 



6.5 Link Manager 

7^ Implementation 



Figure 12 describes a proposed structure for the software. A distributed communications substrate is interposed 
between user processes and the underlying machines, so that processes can generaUy be moved from one machine 
to anotoer without bemg aware of it (either to distribute load or to recover from failures). 

Pro<^« running in the system come from difiFercot sources and accordingly gel different treatment in terms of the 
^^^^^'^"^^'^'^ perfonnance. CaU-processing functions acting on behalf of the end users run in a 
protected sandbox environment on a virtual machine; those working on behalf of the network provider may run 
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FIGURE 1 2. Structure of the proposed network operating system. Signals pass through filter 

processes -p. which also implement drivers and performance-sensitive functions on 
behatt of the network. Call processing on behalf of users ts handled by "CP* processes 
running in a secure virtual machine (Vm^ environment, which also includes 
Checkpointing functions that can trarisfer control on failure to a 'ghost machine" (shown 
as a dotted box for one of the call processing blocks). All these processes run on a 
common software communications layer, which places them on appropriate physical 
systems and arranges tor their connections. Server processes ("S") also run on the 
communications substrate, but do not have the hand real-time constraints of the filter 
processes; secure call-processing functions are one type of server process 



there, but may also be implemented directly as processes running on the network operating system. User processes 
runnmg as "filters". i.e. with the hard real-time demands that come from being in the signal path, also run dirccdy 
on the communications substrate. Processes belonging to different users are protected from each other by the usual 
OS mechanisms (memory mapping, file privileges, etc.) but the source is also reviewed by WST. Filter processes on 
the same machine and pan of the same call may share an address space and a thread of conu-ol. with data being 
passed with a function call mechanism and with connections to other hardware being handled by a stub that adapts 
a function call to a socket-iype mechanism. These filters would still be dynamicaUy linked, even with the funcUon- 
cal mechanism. 

Question for Mike and Mauricio: can we stiU share code segments among many users (20 people aU using the same 
vocoder on a parucular machine, e.g.) with this function^all mechanism? I guess with enough pointers and with 
funcuons mapped into different pages it should be fine and might cut down oa I-cache Tnisscs7 Is this IPR? 

We have to shop around for the right kemeU but QNX is a candidate. A mix of business and technical issues should 
be considered: - - 

• how qiuck is task switching? 

• can we get the source, both to check for security holes aiKl to extend it (for example to aUow the scheduler to 
enforce advanced CPU-sharing policies), 

• what per-unit price is the Ucense. and what special conditions are involved (e.g. the Linux copyleft) 

Mixtion done at execQ level? Daemons watch for things that need to migrate, either because watchdogs faU to 
bark or because queues start to fill up? Queue size anomalies reported to OAM&P. 

processing objects: C code, may assume MMX (good for DSP. likely). Certification involves our seeing source 
which IS also escrowed to us so that failing third parties are not a problem for our users and so that weL^- 
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nate a recompilaiion/rewrite binge to a new CPU if necessary. Ports implemented a bit like sockets, but the system 
can retarget them (to a port on another process, including as a special case a driver to a network device). Poru better 
be fast- Backup of data that must survive crashes handled (in and out?) through a standardized port?. 

8^ IP portfoiio 

this section should outline our plans for patents, trademarks and copyright, 

8.1 System patent 

See 'Telecom Network" 

This protects a networic of patchpoints and basestations. all running simple real-time kernels, all coordinated by a 
middleware layer that gives communications applications a view of the overall system where details of connections 
may be abstracted ouL 



8.2 Graph patent 

Cn See "Method for Configuring Conmiunications Systems" 

o 

This protects the use of a graph structure to describe desired connections, for use in the overall system of 
p Section 8.1. 

[| 8.3 Billing/RFQ patent 

Patent sketch not yet writtcn. 



ii 



This protects the RFQ process: it's a server patent for the system of Section 8. 1. We also protect the use of the 
graphs of Section 8.2 as an APL 



ru 
in 



claims 

1 . use of RFQ mechanism to permit third-party call setup 

2. use of calling graph with policing functions to specify RFQ mechanism 

3. brokers to translate between system and user pricing models, accepting risk 

8.4 Mapping Server patent . _ 

Patent sketch not yet written. 

This protects the mapping server. A system as in Section 8.1 having a process or processes thai add functions (pre- 
ferred embodiment as per Section 8.2) to permit a simplified description of a telecom "cair. possibly including 
blocks representing CJoS policing functions, to be mailed <Mito the physical network- 

8.5 Middleware for Connectivity and QoS 

Patent sketch not yet written. 

Details on functionality of middleware Uycr used in Section 8.1. Is this a continuation? 



32 of 33 



Network Operating System for Telecom 



8.6 Logo trademark 



m 

V' • 

p 

O 
I-- 

!:c 

!fi 

W ! 
'.J 

I! 

P 

ru 
in 

f'Q 



Network Operating Systein for Telecom 33 of 33 



Telecom Network 

patent application draft. Stumm, Sneigrove, De Simone 

Assignee: WST 
Appl. No. 
nied: 

Foreign Application Priority Data 
References Cited 
U.S. PATENT DOCUMENTS 
FOREIGN PATENT DOCUMENTS 
OTHER PUBLICATIONS 

ABSTRACT 

A flexible telecommunications system and a method for allowing flexible and reliable 
configuration of same. 

BACKGROUND OF THE INVENTION 

Overall Background 

telephone systems with "dumb terminals" + large legacy + function too fixed, advanced 
features hard to do 

Internet with smart but untrustworty terminals 
variety of access methods 
variety of switching standards 

Desired Invention 

Therefore, an invention which... is desirable. 

SUMMARY OF THE INVENTION 

should be organized by claim 



Our system comprisi 




1 . A collection of "terminals" (note: we need a better name, since "temiinal" means 
the *phone or the X terminal, and has to be the end of the line: patchpoints? On-ramps? 
TelePorts?) to which the subscriber connects telephones and networked PCs, and which have 
wireless links to... 

2. A collection of basestations. owned by a service provider, interconnected by ... 

3. ... a backbone network, such as an IPor ATM network or a collection of T1 lines. 



4. A distributed operating system on all of the patchpoints and basestations. which 
supports ... 



5. ... "filter" processes that can be moved between computers based on load and 

that... 



6. ... can also be moved on failure of a basestation or patchpoint, perhaps with loss 
of some process state and I/O packets, but without corrupting the structure of interconnection of 
I/O "ports" of the processes, which represents the logical behaviour of the system, and which Is 
p controlled by ... 



7. ... a highly fault-tolerant Java-like (note: explain relevant Java features 

M sandbox, objects. API. download?) software layer that is so rigorously secure that it can be 
£3 safely opened to third-party software developers, 

m 

Application 



ru 
in 

m 



This is the architecture of our data-centric telephony system. Subscribers plug telephones and 
computers into the patchpoints, and software running on the patchpoint relays coded voice or 
data through a wireless modem back to the basestation, and thence through a collection of 
pieces of filtering software (such as coding translators, three-way-calling junctions, DTMF 
detectors, etc.>to other subscribers (or their software proxies). 

Reliability is very important, hence the features relating to redundancy. There is implicit link 
redundancy through the use of a wireless standard that supports handoff. 

Relation to Known Systems 

Elements 1-4 could describe a particular topology of a networked operating system, with the 
relatively minor restriction that 1 and 2 have a wireless interconnection, and with a particular 
ownership structure. A networi< of servers with X temninals would look a lot like what we 
describe to that point. We will in any case wish to extend our system to operate in a wired 
network and with different ownership structures, so these restrictions are not key. 

Element 5 describes the addition that platform computing makes to SUN and NT operating 
systems. The filter & graph view of real-time computing (part of elements 5&6, but for a single- 
user environment with simplified resource management) was in the Katosizer. 



Element 6 is unique. Redundant systems exist, but can only economically switch processes on 
failure between very tightly coupled machines. They are designed to operate with no loss of 
information, whereas we compromise on that to allow realistic performance with redundancy 
between loosely coupled machines. 

The comment "perhaps with some loss ..." means 

• that we can generally tolerate "clicks" etclthat result from losing packets or having filter 
states change discontinuously. but we cannot tolerate an error in state that would result 
in the remainder of the call being useless — for example loss of the codebook in an 
adaptive vector quantizer. Applications that cannot tolerate errors will have to use 
expensive backup mechanisms and multiple paths. 

• that we therefore have a mechanism in the filter API that allows backup across the 
network of state infomiation that must be preserved (keepSafe(Object o) ?), and a 
related mechanism that extends TCP so that we can be certain which packets have 
made it to the other end even when the originator fails during the wait. This will be IPR. 

There will be a good deal of IPR in the definition of the filter objects and API. particularly in 
areas that allow us to make development of filter software as open as possible. 

Element 7 is of central importance for us, since it is what makes it possible for a small company 
to compete with the majors. There will be lots of nuts-and-bolts IPR. but we need to do a very 
careful job of defining and protecting it. 



BRIEF DESCRIPTION OF THE DRAWINGS 

DETAILED DESCRIPTION OF PREFERRED 
EMBODIMENTS OF THE INVENTION 

A coflBcUon of computers interconnected by a network, some of the computers being connected to telephony hardware 
Cir^^udsng anything with microphones, ioudspeakers, posslbty LCD or video displays and possibie videocamerasand } 
wtth as^tware system that enables software components that perform particular taste (such as receding conferendiio* 
etc) to be interconnected and for the connections to be dynamically changed. Use of sockets or funcbon'caUs or 
threads or . 

WE CLAIM 

Broad 

1 . Elements 1-6 of Section, "Summary of the Invention," on page 2 

2. Elements 1-7 of Section, "Summary of the Invention." on page 2 
1. items 1-6 for telecom? 



items 1-7 for telecom 



3. 1-6 fofTfiephony in particular 

4. 1-7 for telephony in particular 
Fair and Square 

5. 

Nuts and Bolts 
6. f 

DRAWINGS 

Drawings describing the problem 

Drawings describing the invention in general terms 

Drawings for preferred embodiments 
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FOREIGN PATENT DOCUMENTS 



OTHER PUBLICATIONS 

O 

p ABSTRACT 

\>0 A structure for configurable software systems applied to telecommunications that allows a 
in library of software components to be interconnected in order to obtain desired behaviours. 



D 



BACKGROUND OF THE irJVENTION 



pi Overall Background 

Telecommunications systems need to process the data flowing through them in complex ways, 
often with processing occurring on computer systems separated both geographically and 
administratively. Many communications paths are simultaneously active, and the processing 
applied to the various flows of data changes frequently and In a wide variety of ways. The 
software needed to control these computer systems is generally large, complex and difficult to 
change. 



When the data flowing through the system represents voice, such as in a modern digital 
telephone network, speoal processing must be applied to implement such features as three- 
way or multi-way calling, voice-mail, voice recognition and authentication, call watting, 
encryption, voice coding and DTMF (dual-tone multi-frequency, tradename TouchTone) 
detection. For data applications in general, such as electronic mail, remote computing, file 
transfer between computers or Web browsing, there are needs for security functions such as 
firewalls and encryption as well as datastream functions such as traffic shaping, error handling, 
prioritization, caching, fonmat translation and multicast. 



\A^ile telecom systems are already complex, new services such as video telephony. Int met 
games, video on demand. Internet audio, remote collaborative work and telemedidne are 
appearing. These services will need new families of features to be overlaid on the existing 
network, rendering the software development task yet more complex. 

The complexity of present telecommunications systems software, and the extensive interactions 
between its software components, makes the development of new features very difficult. 
Software development is therefore limited to a "closed" group of trusted developers, which 
reduces the talent pool available and shuts out developers with new ideas for niche markets. 

application to the modeling of communications systems 

application to the modeling of physical systems 

applications to transaction processing and to computation in general (Mike: I think it's easier to 
make one patent and to arrange ownership of venous markets through contract than to try to 
subdivide a patent, because the umbrella claims have to be smaller in the two-patent case: it 
will be easier to squeeze between the gaps between two umbrellas than to get through one big 
one.) 



Desired invention 

Therefore, an invention which allows the flexible definition of the processing of signals or data 
streams in communications systems, computer systems and computer networks is desirable. 



SUMMARY OF THE INVENTION 

organized by claim 



BRIEF DESCRIPTION OF THE DRAWING 

DETAILED DESCRIPTION OF PREFERRED 
EMBODIMENTS OF THE INVENTION 



WE CLAIM 

Broad 

1 . Anything using graphs to connect pieces of software (need to cut that down a 

bit.,.) 



2 



A configurable software system comprising 
a library of filter processes; 

a software process capable of connecting them in a prescribed fashion; and 
an operating-system kernel capable of executing the connected processes 



3. the software system according to claim 2 implemented on a plurality of 
computers interconnected by a communications network, in which connected filter processes 
may either run on the same or on different computers. 

Fair and Square 

4. the software system according to 3 applied to the processing of data streams ii 
a telecommunications network 



5. 



connected processes able to run in the same address space 



Nuts and Bo!ts 



6. 



function-call model 




Drawings for preferred embodiments 



Drawings describing the invention in general terms 



Drawings describing probiem 



7. 



strongly typed ports 



insertion of drivers for remote connection 



DRAWINGS 



What is claimed is: 

1 . In a telecommunication network including a local client, a local server, a remote server 
and a remote client, said local server and said remote server being operable to 
communicate via a plurality of communication media, a method for selecting one of said 
plurality of communication media to carry a communication service between said local 
client and said remote client, comprising the steps executed at said local server of: 
monitoring performance parameters of said plurality of communication media; 
calculating expected performance of said piuralrty of communication media for handling 

of each of said various modes of communication: and 
determining a usage rate and a warranty to offer to said local client for said 

communication service between said local client and said remote client. 

2. A telecommunications network as claimed In claim 1 , further comprising a third party 
server electrically connected to said local server, wherein said steps of monitoring, 
calculating and determining are executed by said third party server, 

3. A telecommunications network as claimed in claim 1, further comprising the steps of: 
monitoring operation of a communication service; and 

responding to said warranty being violated by providing compensation to said local 
client. 

4. A telecommunications network as claimed In dalm 1 , wherein said step of monitoring 
operation of a communication service comprises recording packet tosses. 

5. A telecommunications network as claimed In daim 1, wherein said step of monitoring 
performance parameters of said plurafity of communication media comprises: 
transmitting sample packets to predetermined destinations within the network; and 
calculating the available quality of service. 



A telecommunications system comprising: 
at least one basestation; 

at least one client access point, each of said client access points being electrically 

connected to a single one of said at least one basestation; 
a backbone network comprising a plurality of communication lines, each of said at least 

one basestations being electrically connected to said backbone network; and 
a distributed operating system on said plurality of basestations and said plurality of client 

access points, being operable to provide switching, billing, voice and data 

services over said telecommunications system. 

A telecommunications system as claimed in claim 6, wherein at least one of said client 
access points is electrically connected to at least one of said basestations via a wireless 
local loop. 

A telecommunications system as claimed in claim 6, wherein said distributed operating 
system is a graph design. 

A telecommunications system as claimed in claim 6. wherein said distributed operating 
system is implemented as a middleware layer, allowing freedom for third parties to add 
operationallity to said telecommunications system. 

In a telecommunication network including a local dient, a local server, a remote server 
and a remote client, said local server and said remote server being operable to 
communicate via a plurality of communication media, a method for selecting one of said 
plurality of communication media to carry a communication service between sakl local 
client and said remote client, comprising the steps executed at said local client of: 
selecting an available communication service on the basis of a usage rate and a 
warranty. 



A telecommunications system c mprising: 
at least one basestatlon; 

at least one client access point, each of said client access points being electrically 

connected to a single one of said at least one basestations; 
a backbone network comprising a plurality of communication lines, each of said at least 

one basestations being electrically connected to said backbone network; and 
agent software operating on said at least one basestatlon and said at least one djdnt 

access point, for negotiating communication services over said backbone 

network. 



A method of communicating voice over data network calls between three or more 
participants comprising the steps of: 

for each participant, mixing voice streams of all other participants together to create a 

composite incoming voice stream; and 
transmitting each said composite incoming voice stream, to the corresponding said 

participant. 

A method of CD^AA wnreiess transmission in v^ich the most distant receiver is identified, 
allowing a reduction in multipath interference and an associated reduction in transmitting 
power. 

A method of CDMA v^reless transmission as claimed In claim 13. wherein said 
transmission is quadrature amplitude modulation. 
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